Export unstable_serialize from SWR
#1337
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit f6b20ef:
|
infinite/index.ts
Outdated
| } | ||
|
|
||
| export const getInfiniteKey = (getKey: KeyLoader<any>) => { | ||
| export const serialize = (getKey: KeyLoader<any>) => { |
There was a problem hiding this comment.
Do you think we should return an array here containing all the custom prefixed keys like $ctx, $len stuff?
That would be easier to access any of them
const serialize = (getKey) => {
const firstPageKey = INFINITE_PREFIX + getFirstPageKey(getKey)
let contextCacheKey, pageSizeCacheKey
if (firstPageKey) {
contextCacheKey = ..
pageSizeCacheKey = ..
}
return [firstPageKey, contextCacheKey, pageSizeCacheKey]
}There was a problem hiding this comment.
Not for now. I'm actually worried about exposing too many implementation details, we should do enough research about use cases (e.g. why do they need to access the infinite context?) before thinking about exposing those.
There was a problem hiding this comment.
I feel the different return type is also bit confusing for new uers (personally), but it's safe to carry on. We can revisit it later.
Would be nice if explicit return type is declared here
There was a problem hiding this comment.
Oh that's a good point. We should probably only return the data key from serialize.
|
This is helpful, however there is no way to retrieve I'm using persistent storage for cache and once an item is removed, I'd like to remove it completely from persistent cache as well. At this moment I'm using: export function deleteCacheEntry(cache: Cache, key: string): void {
const keys = [
key,
'$err$' + key, // errorKey
'$req$' + key, // isValidatingKey
]
keys.forEach(key =>
cache.delete(key)
))
}One prefixes change, such code won't have any effect. |
|
I think one way to simplify all this is, using only 1 key for all states related to that resource and keep those states as object values: // old
cache.set(key, data)
cache.set(errorKey, error)
cache.set(validatingKey, isValidating)
// new
cache.set(key, { data, error, isValidating })This will surely be a breaking change but it would be great to add it. |
|
@shuding good idea |
SWR handles key serialization so it can just pass a string to the cache provider. This makes all the interfaces simpler. However it makes getting data from the cache (or mutating a specific key) tricky, because the serialization util isn't exposed as an API.
Previously we had #1257 to expose the serialization of the
useSWRInfinitekey. This PR unifies the API name, as well as exposing theserializeAPI ofuseSWR.Related: #1324, #1257.